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of  requesting  the  bus  of  0.75  and  a  probability  of  retaining  the  bus  of  0.75), 
the  average  delay  was  seven  cycles. 

The  simulation  program  itself  is  described  in  detail  and  the  results  of 
various  combinations  of  probabilities  are  presented. 
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I.  INTRUUUCTIOM 


Om  problem  chat  coaclnues  to  face  Che  designer  of  computer  systems  in 
which  various  system  elements  must  share  common  resources  is  the  arbitration 
of  access  to  these  resources.  In  most  systems,  this  comes  down  to  the  sharing 
of  a  common  bus  chat  connects  these  resources  to  each  other.  The  question  is: 
how  can  access  to  this  resource,  the  bus,  be  handled  in  a  "fair”  manner?  That 
is,  how  can  one  arrange  for  every  potential  user  of  the  bus  to  have  adequate 
access  to  the  bus  while  preventing  any  one  user  from  monopolizing  it?  Also, 
how  can  this  be  done  in  a  way  Chat  is  the  least  taxing  in  terms  of  hardware 
and  software? 

The  method  put  forth  in  this  paper  for  handling  this  problem  is  a  concep¬ 
tually  siDq>le  solution  involving  a  rotating  priority  systeA.  In  this  way, 
all  boards  at  some  point  would  have  exclusive ,  and  in  some  cases  non-lnterrup- 
Clble,  access  to  the  bus*  Because  Che  priority  rotates,  no  one  individual 
user  of  Che  bus  can  monopolize  it.  This  scheme  is  described  in  the  next 
section. 

Following  this  discussion  of  the  arbitration  algorithm  is  an  extensive 
treatment  of  the  program  used  to  simulate  Che  action  of  the  arbitration 
scheme.  Finally,  there  is  a  discussion  of  Che  results  of  a  number  of  runs 
using  different  values  for  the  probabilities  of  requesting  the  bus  and  of 
completing  a  bus  access. 

II.  ARBITRATION  ALGORITHM  DESCRIPTION 

The  arbitration  scheme  itself  is  conceptually  very  8iaq>le.  The  N  proces¬ 
sors,  or  bus  users,  are  initially  assigned  priorities  of  0  to  N-1,  each  pro¬ 
cessor  receiving  a  different  priority.  While  no  accesses  are  made  to  the  bus, 
or,  more  accurately,  no  processor  releases  the  bus,  the  priorities  remain  the 
same.  However,  when  a  processor  obtains  and  Chen  releases  the  bus,  all  pro¬ 
cessors  have  their  priorities  incremented  by  one  on  a  modulo  N  basis;  that  is, 
the  processor  with  priority  0  goes  Co  priority  1,  priority  N-2  goes  to  N-1, 
and  priority  N-I  goes  Co  0.  In  this  way,  the  highest  priority  processor,  the 
one  with  the  greatest  probability  of  having  had  access  to  the  bus  now  receives 
Che  lowest  priority.  A  "fairer"  method  would  have  the  processor  releasing  the 
bus  receive  the  lowest  priority;  however,  this  would  require  some  method  for 
doing  a  wholesale  reassignment  of  priorities,  whereas  the  method  described 
requires  only  incrementing  counters  on  each  processor. 

However,  once  a  processor  receives  the  bus,  it  does  not  necessarily  have 
non-interruptible  access  to  it;  the  processor  may  lose  the  bus  to  a  processor 
having  higher  priority.  If  this  happens,  the  executing  process  is  blocked, 
the  processor  relinquishes  the  bus,  the  priorities  of  all  the  processors  are 
updated,  and  the  requesting  processor  with  the  highest  priority  is  granted  the 
bus.  The  blocked  processor  now  has  a  pending  bus  request  that  will  be  answered 
when  its  priority  again  exceeds  that  of  all  other  requesting  processors. 
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III.  BUS  SIMULATION  PROGBAM 


In  order  to  develop  an  understandlag  as  to  how  this  syten  would  perfor"- 
over  time,  a  program  was  written  that  will  simulate  the  performance  of  this 
type  of  scheme  over  a  number  of  iterations.  To  allow  for  a  degree  of  varla^ 
bllity,  different  parameters  were  set  up  in  the  form  of  probabilities:  in 
particular,  the  probability  of  a  processor  failing,  of  requesting  the  bus,  and 
of  the  processor  completing  its  bus  access  at  any  particular  time.  In  this 
manner,  different  bus  loads  could  be  simulated.  The  basic  structure  of  the 
simulation  is  described  below.  (See  Appendix  A  for  the  source  code  listing.) 

The  processors  are  represented  in  the  program  as  a  relatively  large  data 
structure  containing  various  flags,  probabilities,  counters,  and  value-holders. 
The  flags  for  each  process  are:  ACTIVE,  which  shows  if  the  processor  is  heal¬ 
thy:  BLOCKED,  which  is  set  if  the  processor  has  the  bus  but  has  been  interrup¬ 
ted;  WAITING,  which  is  set  if  the  processot  has  a  bus  request  which  has  not 
been  met;  and  RUNNING,  which  indicates  that  the  processor  has  run  or  is  run¬ 
ning  since  the  last  time  update.  The  probabilities  contained  in  each  process 
structure  are  those  of  failure  (PROB_JFAIL),  making  a  bus  request  (PROB_R£QUEST) , 
and  of  completing  a  bus  request  on  any  given  cycle  (PROB_COMPLETE) .  The  coun¬ 
ters  contain  information  on  the  cycles  used  in  the  present  block,  wait,  or  bus 
access  (PR£SENT_BLOCK,  PRESENTJiTAIT,  and  PR£SENT_RUN),  the  total  number  of 
cycles  spent  in  blocks,  waits,  or  bus  accesses  (TOTAL_BLOCK,  TOTAL_WAIT, 

NIH.  BLOCKS,  NUM_WAITS,  and  HUM  RUNS).  The  longest  of~any  individual  block,  wait, 
or'nn  is  also  tracked  (LONGESfjaLOCK,  LONG£ST_WAIT,  LONGEST.RUN ) .  Finally, 
and  perhaps  most  important  to  tFls  simulation,  is  PRIORITY,  which  contains  the 
processor's  present  priority. 

To  begin  the  simulation  each  processor  structure  has  its  values  ini¬ 
tialized  through  the  procedure  INIT() .  The  ACTIVE  flag  is  set,  the  BLOCKED, 
WAITING,  and  RUNNING  flags  are  cleared,  the  counters  are  cleared,  and  using 
the  procedure  SET_PRI0RITY(),  the  priority  of  each  processor  is  randomly  set 
to  an  integer  value  between  0  and  N-1  (since  in  this  simulation  the  pro¬ 
cessors  cannot  run  or  request  the  bus  concurrently,  they  oust  Instead  be 
polled  sequentially.)  This  random  setting  of  the  priorities  of  the  different 
processors  helps  to  nullify  any  effects  that  might  occur  due  to  having  the 
processors  arranged  sequentially  by  priority.  After  this,  the  various  proba¬ 
bilities  are  set.  The  program  allows  for  this  to  be  done  randomly  with  a 
default  value  or  with  the  user  specifying  the  probability  for  each  processor 
individually.  These  options  allow  for  the  tailoring  of  the  bus  loading  to 
one's  preference. 

The  main  program  Itself  consists  mainly  of  two  large  loops.  The  outer 
loop  determines  how  many  times  polling  of  the  processors  occurs  and  the  Inner 
loop  determines  how  each  processor  will  act  when  It  Is  polled.  At  the  begin- 
ling  of  the  outer  loop  are  print  statements  that  report  the  status  of  the 
system  every  thousand  iterations.  At  the  end  of  the  outer  loop  is  a  call  to 
the  UPDATE_jriME()  procedure  which  updates  the  counters  within  each  processor 
structure  .'^incrementing  as  necessary  the  number  of  cycles  in  the  RUN,  WAIT,  or 
BLOCK  states.  The  Inner  loop  Is  where  the  actual  computations  that  determine 
processor  state  are  performed.  The  routine  will  check  the  referenced  proces¬ 
sor's  current  state  and  then,  based  on  this  state  and  the  probabilities  asso¬ 
ciated  with  this  processor,  the  next  state  of  the  processor  is  determined. 
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Ac  Che  beglanlag  of  chis  loner  loop,  Che  processor  under  conslderaclon 
may  be  In  one  of  C«o  main  sCaCes,  eicher  healcby  and  funccionlng  (ACTIV£>1)  or 
"dead”  (ACTIVE^O),  having  failed  ac  some  polnc  In  Che  pasc.  If  Che  processor 
is  dead,  Chen  Che  program  conClnues  on  Co  Che  nexc  processor.  Figures  1 
Chrough  3  are  flow  chares  of  chls  porclon  of  che  program. 

On  Che  ocher  hand.  If  Che  processor  has  noc  failed,  1C  will  be  In  one  of 
four  states  as  It  enters  processing.  It  will  either  be  Che  presenc  bus  mascer, 
Ic  will  be  blocked  vlt  had  Che  bus  ac  one  Clme  buc  was  preempCed  before  ic 
could  complete  the  transaction).  It  will  be  waiting  (Che  processor  has  requesc-* 
ed  Che  bus,  but  has  not  yet  received  It),  or  It  could  have  no  pending  requests. 
Each  of  these  states  requires  that  different  actions  be  taken  and  each  have 
different  alternatives  to  choose.  Each  of  these  alternatives  is  chosen 
chrough  the  use  of  the  probabilities  assigned  to  each  processor  and  che 
actions  of  a  random  number  generator.  Any  clme  che  value  received  from  the 
random  number  generator  la  less  than  Che  value  of  the  assigned  probability, 
che  action  associated  with  Chat  probability  will  be  performed. 

The  first  state  to  be  looked  at  Is  that  of  che  processor  being  the  pre¬ 
senc  bus  master.  This  Is  perhaps  che  simplest  of  all  Che  states  Co  process. 

The  first  check  Is  Co  see  If  Che  processor  fails  at  this  point.  If  It  does, 
Chen  ics  ACTIVE  flag  Is  cleared,  BUSJ1ASTE&  and  PRIORITY  are  sec  to  FREE,  and 
UFDATE_PRIORITY()  la  called.  If  the^ptocessor  remains  active,  Chen  RUN_PRO- 
CESS()~l8  called  Co  see  If  Che  processor  will  complete  Its  access  chls  ^ycle. 
The  program  Chen  conClnues  on  Co  Che  next  processor. 

RUNJPROCESSO  Is  a  very  simple  routine  Itself.  If  Che  PROB_COMPL£T£ 
associated  with  this  process  Is  greater  than  some  random  number,  then  che  bus 
Is  freed  again.  UPQATE_FR10RITIES()  Is  then  called. 

With  the  next  three  states,  BLOCKED,  WAITING,  and  NO_P£NDING_R£QUESTS , 
again  the  possibility  of  processor  failure  Is  checked  first,  and,  with  these 
three,  che  processing  Is  the  same.  If  the  processor  does  fall,  ACTIVE  is 
cleared,  L0NGEST_WAIT ,  LONGEST JiLOCK,  TOTAL_WAIT,  and  TOTAL_BLOCK  are  all 
updated  with  respect  to  PRESENf|_WAlT  and  PR£SENT_BLOCK.  The  flags  WAITING  and 
BLOCKED  are  then  cleared. 

The  next  check  made  on  processors  In  one  of  these  three  states  is 
whether  or  noc  It  will  make  a  request  for  the  bus.  For  the  BLOCKED  and 
WAITING  states  Chls  Is  automatic.  For  che  NO  PENDING_KEQUESTS  state,  Chis  is 
checked  chrough  Its  PROB_REqUEST  value.  If  there  Is  no  request,  the  program 
goes  on  CO  che  nexc  processor. 

Next,  having  made  a  request  for  the  bus,  the  priority  of  the  requester 
Is  coo^pared  to  Chat  of  che  presenc  bus  mascer,  chat  Is,  to  the  value  stored  in 
the  global  variable  PRIORITY.  If  che  priority  of  the  requester  Is  the  lesser 
of  Che  two  values,  Chen  che  program  continues  on  with  che  next  processor; 
otherwise,  che  requesting  processor  becomes  the  new  bus  master.  If  the  bus  is 
free,  then  chls  Is  accomplished  by  writing  che  processor's  number  Into 
BUS^MASTER,  Its  presenc  priority  Into  PRIORITY,  and  Its  BLOCKED  and  WAITING 
flags  cleared.  After  chls,  RUN__PROCESS( )  Is  called  co  see  If  it  will  complete 
Its  access  In  this  cycle.  The  program  Chen  conClnues  on  to  Che  nexc  processor. 
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If,  on  the  other  head,  the  bus  is  aot  free  when  the  requester  receives 
the  bus,  the  old  bus  master  must  be  blocked.  This  is  accomplished  by  setting 
the  bus  master's  BLOCKED  flag,  incrementing  Its  NUM_BLOCKS,  and  calling 
UPDAIE_FBIORITIES().  The  requester  Is  then  given  control  of  the  bus  as  In  the 
previous  paragraph. 

After  the  program  has  stepped  through  all  N  of  the  processors.  It  Is 
considered  to  have  completed  one  BUS  CYCLE.  At  the  end  of  each  bus  cycle,  the 
routine  UPOATE_TIME()  Is  called  In  order  to  keep  track  of  the  amount  of  time 
spent  by  each  processor,  either  on  the  bus,  waiting  for  Initial  access  to  the 
bus,  or  In  a  blocked  state.  The  routine  looks  at  each  processor  data  struc¬ 
ture,  looking  at  what  flags  are  set,  and  updating  the  appropriate  tliaes. 

First,  It  looks  at  the  RUNNING  flag.  If  It  Is  set  and  the  processor  Is  the 
present  bus  master,  then  PRESENT__RUN  Is  Incremented  and  LONGEST_RUN  Is  updat¬ 
ed.  If  It  Is  not  the  bus  master,  then  PRESENT^RUN  Is  cleared.  In  any  case, 
the  RUNNING  flag  Is  cleared.  Next,  UPDATE  TIME()  checks  the  BLOCKED  and 
WAITING  flags  and  updates  either  PRESENTJf^T  or  PRESENT_BLOCK,  respectively. 
Finally,  the  routine  sets  the  RUNNING  flag  of  the  PRESEN^BUS  master. 

At  this  point,  there  may  exist  some  confusion  over  why  UPDATE^TIM£() 
clears  and  then  sets  the  RUNNING  flag  while  the  other  flags  are  lef?  alone. 

The  reason  Is  that,  with  the  structure  of  the  simulation,  once  a  processor  Is 
put  on  WAIT  or  BLOCK,  It  remains  there  until  the  next  bus  cycle.  On  the  other 
hand.  If  It  Is  running.  It  may  be  blocked  any  time  during  the  present  cycle  or 
some  future  cycle.  In  order  to  keep  track  of  the  amount  of  time  some  pro¬ 
cessor  had  the  bus.  It  Is  assumed  that  the  processor  keeps  the  bus  for  one 
entire  cycle  If  It  had  the  bus  for  any  portion  of  that  cycle.  For  this 
reason,  when  a  processor  Is  blocked,  the  RUNNING  flag  Is  not  reset  until 
UPDAI£_TIME()  Is  called  at  the  end  of  the  cycle.  In  this  way,  all  the  pro¬ 
cessor?  that  ran  during  the  cycle  get  credit  for  that  cycle,  and  by  setting 
the  bus  master's  RUNNING  flag  again.  It  will  get  credit  the  next  time  the 
update  routine  Is  called  at  the  end  of  the  next  cycle. 

After  the  outer  loop  has  run  the  required  number  of  Iterations  (10,000 
In  this  simulation),  the  results  are  tallied.  The  total  amount  of  time  spent 
running  In  a  WAIT  or  In  a  BLOCK  Is  tallied,  as  well  as  the  total  number  of 
times  processors  were  put  In  a  RUN,  WAIT,  or  BLOCK.  From  these,  average  times 
may  be  computed.  Also  reporteo  are  the  longest  times  In  any  state. 
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IV.  SIMULATION  RESULTS 


Appendix  B  gives  the  results  of  a  nuaber  of  runs.  The  first  three  use 
random  values  for  the  probabilities  of  failure,  request,  and  completion.  (The 
intermediate  results  from  the  first  run  are  presented  in  order  to  give  the 
reader  an  idea  of  what  is  displayed  during  a  run.)  As  can  be  seen  from  these, 
although  the  total  times  and  longest  times  spend  in  a  WAIT  or  BLOCK  state  have 
considerable  variation  from  one  run  to  another,  the  average  time  in  a  WAIT  or 
BLOCK  remains  consistently  small,  generally  less  than  10  cycles.  In  addition, 
the  total  number  of  cycles  in  which  the  bus  was  active  remained  relatively 
constant . 

The  rest  of  the  runs  presented  represent  situations  that  range  from  a 
very  heavily  loaded  bus  (a  high  probability  of  requesting  the  bus  along  with  a 
low  probability  of  completing  an  access)  to  a  very  lightly  loaded  bus  (a  low 
probability  of  request  with  a  high  probability  of  completion.)  As  can  be  seen 
on  the  heavy  loading  run,  although  the  number  of  cycles  the  bus  is  Is  use 
Increases  by  about  half  over  the  fandom  loading,  the  amount  of  time  in  a  BLOCK 
or  WAIT  more  than  doubles.  However,  the  average  time  spent  in  a  BLOCK  or  WAIT 
is  still  under  10  cycles  -  the  same  as  with  the  random  case.  The  next  case, 
high  probability  for  both  request  and  completion,  is  perhaps  the  ideal  bus 
loading  situation.  Bus  utilization  is  more  than  doubled  over  any  other  case. 
In  addition,  the  average  WAIT  and  BLOCK  is  down  to  one. 

The  case  in  which  both  the  probabilities  are  low  (a  request  is  not 
likely,  but  if  there  is  one,  it  is  not  likely  to  complete  on  any  given  cycle) 
is  about  average  when  compared  to  the  other  cases.  The  average  delays  are  In 
the  same  range  as  all  the  others,  under  10  cycles,  and  because  there  are  fewer 
requests,  the  bus  is  used  less  often  than  the  higher  request  situations,  even 
the  one  with  the  high  blocking  rate.  The  final  situation,  with  low  request 
probability  and  high  completion  probability,  has  the  lowest  rate  of  blocking 
and  waiting,  though  not  much  lower  than  the  high  request/high  complete. 

Again,  because  the  request  rate  is  low,  bus  utilization  is  dropped. 

V.  CONCLUSIONS 

This  system  of  bus  arbitartlon  using  a  rotating  priority  scheme  appears  to 
be  an  effective  and  efficient  method  of  handling  bus  arbitration.  Average 
delays  are  consistently  low  in  all  cases  tested;  failure  of  individual  system 
elements  appears  to  have  little  effect  on  overall  system  performance;  and  the 
conceptual  simplicity  of  the  system  should  allow  for  relatively  efficient 
Implementations  in  hardware. 
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Figure  2.  Flowchart  of  bus  master  processing  loq£. 
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APPENDIX  A 


SOURCE  CODE  LISTING 


^  Init.e  *  Houtlnt  to  InltUliw  wrlibiM  for  computation 


Set  tha  vaiuM  far  tha  varleua  prokabClftlaa  */ 


Itdi  ((intMnanar) 


a  'I': 

•  *r*s 

i 


asSfel^SSfafeaSr 


pr1nCf(«M^babUlty  of  faUura  Xdi  Xf\n*,1,Preearray(n .Pretafail); 


V1nifiaitf«lAt.va! 


^  {I  •  0;  I  <  IMMOCenOM;  i*r) 

pr<nrtgVi>rttiaMHty  of  faUura  for  pracaaacr  Xd;  ".I); 


rayt1]Tpraffatl  >  Waluo; 


grfngfCVf); 


Sourea  Lino 

dafaul 


Nicroooft  C  Ceapilar  varaien  4.00 


clo*p(3yf*‘ 


rtoeffrvtf) 


^iritdi  «int)<naiiar) 


buo  raquaatvn*); 


|oii1-0;  t<«MFKnsaORS;  1r«) 

IKquSi^id:  Xf\n",l,ProeA>Tay[fj  .ProbRequeat) 


(f  ■  0;  (  <  mpwcgtiail;  i««) 


<  mpwcgtiaii;  !««) 

|]Pr|MU|^  of  raquaat  for  procaaaor  Xd  ■,<); 
Cfi^roSa^uaat  ■  valua; 


|rlnjf<-Vi-); 


jrfnrfjg^.  Vary  dMb.  Try  again. Vf>); 


^ncf("NnP); 


^tdi  ((IntMnaMar) 


buB  acceta\n"); 


I*  KM  U  fr««  •/ 

ffiteS'™'" 


raNcStU^fSAr^Ul.^rtbCaiplvt*); 
>  bui  is  trm  •/ 

r  %xis 


Niersssft  C  Csspilsr  Vsrsion  4.00 


if  (isr«c*mrtj].llsefcsd  at  iSrocArnvtJJ.Usitint) 

es»s(fldciiss%:.;'' 


'’'pssm&srii'iU' 

"'Sr!nSW&iSS‘f!i>  nmr  UMUdlW.Ol 
*''gi3CTSitiSgg*~~-  M  «.  talvo,  <> 

'<iae£A'.'RSt!7(!l)i^Eassas, 

'nasinb.'.'iisiRRitit'Si!^, 

'naaBSi%'Ri9»eUi«ais!! 


inal  Sourcit  Lins 


Nfersssft  C  Cci^lsr  Vsrsien  4.00 
:  UKiSrf.  SWM.locklimMMAiQCi^); 


.dv,  ««*-«<»> 


APPENDIX  B 


RESULTS  OF  RUNS 


D. 


.  Rn  4:  Biig^  BenhwiaiUty  of 

»  you^iti  to  Mt  the  probibilitiM  of  faUuro 
UglUj^t  valuo? 

B  yauidah  to  aat  tho  probabUttloa  of  Making  a  bua  roquaat 

- 

tfault  valua? 


RdafailitY  of  OMp1al:ion 


fault  valua? 


ab  to  tat  tho  probabilltlao  of  eoiplotlng  a  bua  aeeata 
or 


E.  Boa  5:  Hi^  Rcfaafaili^  of  ItaqaBBVSLgii  Rxtability  xxC  Qaqileticn 


liSM 


^ah  to  tat  tho  probablUtloa  of  fallura 


t  valua? 


ah  to  tat  tho  prababflitioa  of  Making  a  but  ra^jaat 


ault  valua? 


or 


^ah  to  aat  tho  probabllltioa  of  eonplotlng  a  bua  aceaaa 


fault  valua? 


F.  am  6:  Iflv  axUbdlity  of 

Do  you  triih  to  Mt  tho  probibUitloa  of  faUuro 

•Ittll"' 


RniiBfailltY  of  Gb^ilstiai 


valua? 


Hr; 

fault  vsluoT 


aat  tba  prababfUtlaa  of  oaklns  a  bua  raquMt 
or 


■b  to  aat  tha  probabUftlaa  of  eoiplating  a  bua 


fault  valuaT 


fKflw-  *• 


jj^t  valua? 

]ab  to  aat  tha  probabUltlaa  of  aakinp  a  bua  raquaat 
or 


jfault  valua? 
g.»Ljf1«»»  to  a 


aat  tha  probbbilltiaa  of  coatilatinB  a  bua  accaaa 
or 


fault  valua? 
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